Siimeloni scalartype color lookup #1
Conversation
This is implemented in the writer and parser.
SwishSwushPow
changed the base branch from
master
to
Siimeloni-patch-binary-color-fix
There was a problem hiding this comment.
Hi @elrnv , thanks for your code suggestions! I like your approach to add a new function for this specific case. I have a couple of questions and suggestions that I would love to discuss before we merge this. But if these are resolved I think this can go ahead and get merged (and then get merged into vtkio). Thank you again for looking into this!
| @@ -176,6 +176,8 @@ mod write_vtk_impl { | |||
| DataSet(DataSetError), | |||
| NewLine, | |||
|
|
|||
| InvalidColorScalarsType, | |||
There was a problem hiding this comment.
It seems that this error is not used anywhere. Maybe it could be used in the write_color_scalars_buf functions below? Otherwise we should remove it I think.
| (input.into() * 255.0).round().clamp(0.0, 255.0) as u8 | ||
| } | ||
|
|
||
| match buf { |
There was a problem hiding this comment.
As your error description above describes we only dealt with f32 and u8 at the moment. Do you think we should accept all types right away or should we restrict it somehow and use the error above here? Same applies for the function implemented for the AsciiWriter.
There was a problem hiding this comment.
Good call! I was on the fence about whether the conversion should be lenient. I think most likely scenario is that users will create colour scalars with the right range of values, but may make an error in the type. I originally had it return the error, but then decided we might as well just convert since the conversion seemed like it would address the 99% of the errors anyways. I guess this kinda goes against the explicitness of most Rust code. What are your thoughts?
There was a problem hiding this comment.
Honestly we might as well handle all the cases if we have a look at this now. Though I am not sure if all cases are handled coherently yet. In general I think that at the end of the day we should be roundtrip safe. So binary -> ascii -> binary/ascii -> binary -> ascii should always lead to the same results. I'm not sure if that is the case yet. The tests I've mentioned in the other comment could be very helpful for that. I have added a couple more comments down below to explain what I mean.
Edit: Actually it is only the one Bit location where I think we don't need the multiplication. The other places look good. I'm interested to see if a test confirms that. Also if we handle all cases, the error above can be removed. 👍
| test_b!(parse_ne(Vec::<u8>::new().write_vtk_ne(out1.clone())?) => ne(&out1)); | ||
| test_b!(parse_le(Vec::<u8>::new().write_vtk_le(out1.clone())?) => le(&out1)); | ||
| test_b!(parse_be(Vec::<u8>::new().write_vtk_be(out1.clone())?) => out1); | ||
| test_b!(parse_ne(Vec::<u8>::new().write_vtk_ne(out1_bin.clone())?) => ne(&out1_bin)); |
There was a problem hiding this comment.
I think it would make sense to add two new tests here that write the binary input (out1_bin, out2_bin) into a string and see if that conversion works correctly. Should be easy enough, right?
| (input.into() * 255.0).round().clamp(0.0, 255.0) as u8 | ||
| } | ||
|
|
||
| match buf { |
There was a problem hiding this comment.
Honestly we might as well handle all the cases if we have a look at this now. Though I am not sure if all cases are handled coherently yet. In general I think that at the end of the day we should be roundtrip safe. So binary -> ascii -> binary/ascii -> binary -> ascii should always lead to the same results. I'm not sure if that is the case yet. The tests I've mentioned in the other comment could be very helpful for that. I have added a couple more comments down below to explain what I mean.
Edit: Actually it is only the one Bit location where I think we don't need the multiplication. The other places look good. I'm interested to see if a test confirms that. Also if we handle all cases, the error above can be removed. 👍
| } | ||
|
|
||
| match buf { | ||
| IOBuffer::Bit(v) => write_buf_impl(v, &mut self.0, |x| x * 255 as u8)?, |
There was a problem hiding this comment.
Although Bit has the same content as U8 we multiply by 255 here. Is that needed? The other cases are handled coherently I think, but this sticks out a little bit.
| write_buf_impl(v, &mut self.0, convert_int)?; | ||
| } | ||
| IOBuffer::U64(v) => { | ||
| write_buf_impl(v, &mut self.0, |x| 0.max(x) as f32 / 255.0)?; |
There was a problem hiding this comment.
I think this can use convert_int as well?
|
Just FYI I've decided to merge this PR for now and tackle the locations where I commented myself. If there are any things to discuss I think we can do this on the PR that will target |
SwishSwushPow
merged commit 7311794
into
GiGainfosystems:Siimeloni-patch-binary-color-fix
|
Thanks for moving this forward! Sorry I wasn’t able to make the changes sooner. For the future, I think you can also just directly push changes to a PR, if the author allows (which I think is the default case and the case here too) |
|
No worries. I'm not too familiar with open source work yet so that's why I'm a bit more cautious and at least I think I would always ask before pushing things on other peoples branches. 😅 But in this case since we had this working branch already (and we need to merge this back to |
Adding a legacy writer implementation to correctly write color scalars in U8 when using binary and f32 when using ascii writers.